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DETAILED ACTION 

1 . This office action is responsive to application No. 10/773,298 filed on 
04/03/2008. Claims 1-7 and 9-20 are pending and have been examined. 

Response to Arguments 

2. Applicant's arguments with respect to claims 1 -7 and 9-20 have been 
considered but are moot in view of the new ground(s) of rejection. 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described 
as set forth in section 102 of this title, if the differences between the subject matter sought to 
be patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to which 
said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 

4. Claims 1-4, 6, 7, 10, 12, 14, 16, 17, 19, and 20 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Solle et al (US 6,757,732), in view of 
ISO/IEC 13818-6 (First edition 1998-09-01), and further in view of Goffin, II (US 
6,918,135). 

Consider claim 1, Solle teaches a method for controlling network 
digital service, comprising steps of: 

directly requesting, at a client, without passing through a network 
session resource manager, a digital server for a session connection, and 
establishing a session by receiving, without passing through said network 
session resource manager, a confirmation message for the session 
connection from the digital server (Fig.1, 12; Col 5: lines 26-32, 39-41 
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teaches that SIP systems can be either SIP clients or SIP servers, and 
direct session communications between SIP systems. Col 9: line 49 - Col 
10: line 15 teaches establishing a session between SIP systems where an 
invite message {request from client} is sent and an Ok {confirmation} is 
received from the server. These communications are direct from client to 
server as taught by Col 5: lines 39-41 and shown on Fig. 12, without 
passing a session resource manager); and 

Solle does not explicitly teach a digital broadcasting server and 
service; 

directly requesting at the client, without passing through said 
network session resource manager, the digital broadcasting server for a 
channel change, and changing a channel by receiving, without passing 
through said network session resource manager, a confirmation message 
for confirming the channel change from the digital broadcasting server, 

wherein a message for requesting the channel change and the 
confirmation message for confirming the channel change each include a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field, the message for requesting the channel change is a 
ProgramSelectRequest message including: a DSM-CC (Digital Storage 
Media-Command and Control) message header field, a Session ID 
(Identification) field, a STB (Set Top Box) status field, a broadcast 
Programld field, a Client ID field, and the ProgramSelectRequest message 
is transmitted from the client to the digital broadcasting server. 
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In an analogous art ISO/IEC 13818-6 teaches, a digital 
broadcasting server and service (P.492-495 teaches a SDB-Server); 

directly requesting, at the client, without passing through said 
network session resource manager, the digital broadcasting server for a 
channel change, and changing a channel by receiving , without passing 
through said network session resource manager, a confirmation message 
for confirming the channel change from the digital broadcasting server (P. 
492-495 teaches a client directly requesting a broadcast program from the 
SDB Server. A SDBProgramSelectRequest is generated by the client and 
sent to the SDB Server for requesting a channel change. A 
SDBProgramSelectConfirm from the SDB Server is received by the client 
allowing the client to receive the requested Broadcast Program), 

wherein a message for requesting the channel change and the 
confirmation message for confirming the channel change each include a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field (P. 492-493; Fig. H-4. protocolDiscriminator, dsmccType, 
messageld, transcationld, reserved, adaptationLength, messageLength 
make up a DSM-CC message header field as taught in clause 2 on p. 7, 
which are all present in both messages for channel change and 
confirmation. P. 291 Sections 10.1.2-10.2), the message for requesting 
the channel change is a ProgramSelectRequest message including: a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field (P. 492-493; Fig. H-4. protocolDiscriminator, dsmccType, 
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messageld, transcationld, reserved, adaptationLength, messageLength 
make up a DSM-CC message header field as taught in clause 2 on p. 7, 
which are all present in both messages for channel change and 
confirmation. P. 291 Sections 10.1.2-10.2), a Session ID (Identification) 
field, a broadcast Programld field, and the ProgramSelectRequest 
message is transmitted from the client to the digital broadcasting server 
(Table 10-5, P.293 Section 10.2.3.1). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify Solle's system to include a digital broadcasting server 
and service; directly requesting at the client, without passing through said 
network session resource manager, the digital broadcasting server for a 
channel change, and changing a channel by receiving, without passing 
through said network session resource manager, a confirmation message 
for confirming the channel change from the digital broadcasting server; 
wherein a message for requesting the channel change and the 
confirmation message for confirming the channel change each include a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field, the message for requesting the channel change is a 
ProgramSelectRequest message including: a DSM-CC (Digital Storage 
Media-Command and Control) message header field, a Session ID 
(Identification) field, a broadcast Programld field, and the 
ProgramSelectRequest message is transmitted from the client to the 
digital broadcasting server, as taught by ISO/IEC 13818-6, for the 
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advantage of allowing for a more flexible and versatile system, in order to 
be easily used in a digital broadcasting environment, allowing the client to 
switch channels with ease, providing the server with all the necessary 
information allowing the server to react swiftly and accordingly to client 
demands. 

Solle and ISO/IEC 13818-6 do not explicitly teach the message 
includes a STB (Set Top Box) status field, and a Client ID field. 

In an analogous art Goffin teaches, a channel request message 
includes a STB (Set Top Box) status field, and a Client ID field (Col 3: 
lines 49-61 , Col 4: lines 49-51 teaches transmission of video from a 
headend and a data router 202 that facilitates headend communications 
with the client device. Col 5: lines 34-44 and Col 6: lines 14-24 teaches 
that the data router 202, receives both the STB status and client ID from 
the client device). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle and ISO/IEC 13818-6 to include a 
STB (Set Top Box) status field, and a Client ID field with the channel 
change request message, as taught by Goffin, for the advantage of 
notifying the server of the state and requests of the STB, and also allowing 
the server to easily and readily determine the source of the message. 

Consider claim 17, Solle teaches a system controlling a network 
digital service comprises: 
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a client and a digital server, the client directly requesting, without 
passing through a network session resource manager, the digital server 
for a session connection, and establishing a session by receiving, without 
passing through said network session resource manager, a confirmation 
message for the session connection from the digital server (Fig.1 , 1 2; Col 
5: lines 26-32, 39-41 teaches that SIP systems can be either SIP clients or 
SIP servers, and direct session communications between SIP systems. 
Col 9: line 49 - Col 10: line 15 teaches establishing a session between 
SIP systems where an invite message {request from client} is sent and an 
Ok {confirmation} is received from the server. These communications are 
direct from client to server as taught by Col 5: lines 39-41 and shown on 
Fig. 12, without passing a session resource manager); and 

Solle does not explicitly teach a digital broadcasting server and 
service; 

the client directly requesting, without passing through said network 
session resource manager, a program change from the digital server and 
receiving a confirmation message, without passing through said network 
session resource manager, from the digital server, when the digital 
broadcasting server confirms the program change. 

wherein a message for requesting the program change and the 
confirmation message confirming the program change each include a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field, the message for requesting the channel change is a 
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ProgramSelectRequest message including: a DSM-CC (Digital Storage 
Media-Command and Control) message header field, a Session ID 
(Identification) field, a STB (Set Top Box) status field, a broadcast 
Programld field, a Client ID field, and the ProgramSelectRequest message 
is transmitted from the client to the digital broadcasting server. 

In an analogous art ISO/IEC 13818-6 teaches, a digital 
broadcasting server and service (P.492-495 teaches a SDB-Server); 

the client directly requesting, without passing through said network 
session resource manager, a program change from the digital server and 
receiving a confirmation message, without passing through said network 
session resource manager, from the digital server, when the digital 
broadcasting server confirms the program change (P. 492-495 teaches a 
client directly requesting a broadcast program from the SDB Server. A 
SDBProgramSelectRequest is generated by the client and sent to the 
SDB Server for requesting a channel change. A 

SDBProgramSelectConfirm from the SDB Server is received by the client 
allowing the client to receive the requested Broadcast Program), 

wherein a message for requesting the program change and the 
confirmation message confirming the program change each include a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field (P. 492-493; Fig. H-4. protocolDiscriminator, dsmccType, 
messageld, transcationld, reserved, adaptationLength, messageLength 
make up a DSM-CC message header field as taught in clause 2 on p. 7, 



Application/Control Number: 10/773,298 
Art Unit: 2623 

which are all present in both messages for channel change and 
confirmation. P. 291 Sections 10.1.2-10.2), the message for requesting 
the channel change is a ProgramSelectRequest message including: a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field (P. 492-493; Fig. H-4. protocolDiscriminator, dsmccType, 
messageld, transcationld, reserved, adaptationLength, messageLength 
make up a DSM-CC message header field as taught in clause 2 on p. 7, 
which are all present in both messages for channel change and 
confirmation. P.291 Sections 10.1.2-10.2), a Session ID (Identification) 
field, a broadcast Program Id field, and the ProgramSelectRequest 
message is transmitted from the client to the digital broadcasting server 
(Table 10-5, P.293 Section 10.2.3.1). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify Solle's system to include a digital broadcasting server 
and service; the client directly requesting, without passing through said 
network session resource manager, a program change from the digital 
server and receiving a confirmation message, without passing through 
said network session resource manager, from the digital server, when the 
digital broadcasting server confirms the program change; wherein a 
message for requesting the program change and the confirmation 
message confirming the program change each include a DSM-CC (Digital 
Storage Media-Command and Control) message header field, the 
message for requesting the channel change is a ProgramSelectRequest 
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message including: a DSM-CC (Digital Storage Media-Command and 
Control) message header field, a Session ID (Identification) field, a 
broadcast Programld field, and the ProgramSelectRequest message is 
transmitted from the client to the digital broadcasting server, as taught by 
ISO/IEC 13818-6, for the advantage of allowing for a more flexible and 
versatile system, in order to be easily used in a digital broadcasting 
environment, allowing the client to switch channels with ease, providing 
the server with all the necessary information allowing the server to react 
swiftly and accordingly to client demands. 

Solle and ISO/IEC 13818-6 do not explicitly teach the message 
includes a STB (Set Top Box) status field, and a Client ID field. 

In an analogous art Goffin teaches, a channel request message 
includes a STB (Set Top Box) status field, and a Client ID field (Col 3: 
lines 49-61 , Col 4: lines 49-51 teaches transmission of video from a 
headend and a data router 202 that facilitates headend communications 
with the client device. Col 5: lines 34-44 and Col 6: lines 14-24 teaches 
that the data router 202, receives both the STB status and client ID from 
the client device). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle and ISO/IEC 13818-6 to include a 
STB (Set Top Box) status field, and a Client ID field with the channel 
change request message, as taught by Goffin, for the advantage of 
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notifying the server of the state and requests of the STB, and also allowing 
the server to easily and readily determine the source of the message. 

Consider claim 2, Solle, ISO/IEC 13818-6, and Goffin teach a client 
receiving messages from a digital broadcasting server, and the client 
directly delivering messages to the digital broadcasting server (Solle - 
Fig. 12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492-495 teaches a SDB- 
Server). 

ISO/IEC 13818-6 further teaches receiving at a client a message 
for checking a status of the client, and delivering a confirmation message 
for checking the status of the client (P.90-91 teaches that the client can 
receive a ClientStatuslndication message which requests information. 
The client in turn sends back a ClientStatusResponse containing the 
information that was requested. Referring back to Table 4-16 on P. 56, 
many different statusType fields can be used for specifying what type of 
status is requested including the status of the client). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include receiving at a client a message for checking a status of the client, 
and delivering a confirmation message for checking the status of the 
client, as further taught by ISO/IEC 13818-6, for the advantage of allowing 
the server to check on the state of the client in order to provision and 
utilize network resources more efficiently. 
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Consider claim 3, Solle, ISO/IEC 13818-6, and Goffin teach directly 
terminating a session between client and server (Solle - 624-Fig.12; Col 
10: lines 36-38) and a client and a digital broadcasting server, directly 
requesting/receiving messages (Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 
13818-6 - P.492-495 teaches a SDB-Server). 

ISO/IEC 1 381 8-6 further teaches, requesting, at the client for a 
session termination and terminating a session by receiving a confirmation 
message for the session termination (P. 81-82 teaches a client initiating a 
release request. Step 1 teaches the client sending a 
ClientSessionReleaseRequest message for releasing an existing session. 
Step 4-5 teaches receiving a ClientSessionReleaseConfirm message 
terminating the session). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include requesting, at the client for a session termination and terminating a 
session by receiving a confirmation message for the session termination, 
as further taught by ISO/IEC 1 381 8-6, for the advantage of allowing the 
client to end connection with the server in a clean and efficient manner, 
allowing both parties to disconnect cleanly in a timely manner, allowing 
resources to be freed back into the network. 
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Consider claim 4, Solle, ISO/lEC 13818-6, and Goffin teach a client 
and a digital broadcasting server, directly requesting/receiving messages 
(Solle - Fig. 12; Col 5: lines 39-41; ISO/lEC 13818-6 - P.492-495 teaches a 
SDB-Server). 

ISO/lEC 13818-6 further teaches, requesting the client for a 
session termination and terminating a session by receiving a confirmation 
message for the session termination from the client (P. 87 - 88, step 2 
teaches sending a ClientSessionReleaselndication to the client for 
releasing an existing session. The ClientSessionReleaseResponse is 
received from the client and releases all the resources assigned to the 
session and terminates the session for the client). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/lEC 13818-6, and Goffin to 
include requesting the client for a session termination and terminating a 
session by receiving a confirmation message for the session termination 
from the client, as further taught by ISO/lEC 13818-6, for the advantage of 
allowing the server to end connection with the client in a clean and 
efficient manner, allowing both parties to disconnect cleanly in a timely 
manner, allowing resources to be freed back into the network. 

Consider claim 6, ISO/lEC 13818-6 further wherein a protocol 
between the client and the digital broadcasting server is a TCP/IP (P. xxv 
teaches that the transport layer in Fig. 0-3 on P. xxiv may consist of any 
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protocol including TCP over IP. P. 291 also teaches that Switched Digital 
Broadcast (SDB) Channel Change Protocol (CCP) can be carried on top 
of various protocols including IP where their constraints are further defined 
in clause 9, allowing for the use of TCP over IP). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include wherein a protocol between the client and the digital broadcasting 
server is a TCP/IP, as further taught by ISO/IEC 13818-6, for the 
advantage of providing for a more robust and versatile system built upon 
an industry standard and time tested protocol. 

Consider claim 7, Solle, ISO/IEC 13818-6, and Goffin teach a 
message for requesting the session connection is transmitted from the 
client to the digital broadcasting server (Solle - Fig.1, 12; Col 5: lines 26- 
32, 39-41 teaches that SIP systems can be either SIP clients or SIP 
servers, and direct session communications between SIP systems. Col 9: 
line 49 - Col 10: line 15 teaches establishing a session between SIP 
systems where an invite message {request from client} is sent and an Ok 
{confirmation} is received from the server; ISO/IEC 13818-6 - P.492-495 
teaches a SDB-Server). 

ISO/IEC 13818-6 further teaches wherein a message for requesting 
the session connection is a SessionSetupRequest message including: a 
DSM-CC (Digital Storage Media-Command and Control) message header 
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field, a Session ID (Identification) field, a Reserved field, a Client ID field, 
and a Server ID field (ISO/IEC 13818-6 - 4.2.4.1 on P. 25-26, and Table 4- 
8). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include wherein a message for requesting the session connection is a 
SessionSetupRequest message including: a DSM-CC (Digital Storage 
Media-Command and Control) message header field, a Session ID 
(Identification) field, a Reserved field, a Client ID field, and a Server ID 
field, as further taught by ISO/IEC 1 381 8-6, for the advantage of allowing 
for a more flexible and versatile system, in order to be easily used in a 
digital broadcasting environment, where the message can easily be sent 
to the correct server, allowing the server to easily process and execution 
the session connection for the appropriate client. 

Consider claim 10, Solle, ISO/IEC 13818-6, and Goffin teach a 
client and a digital broadcasting server, directly requesting/receiving 
messages (Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492- 
495 teaches a SDB-Server), and a wherein a message for requesting a 
session termination is a ClientReleaseRequest message including: a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field, a session ID field, a Reason field (ISO/IEC 13818-6 - P.28 Section 
4.2.5.1 ), but do not explicitly teach a ClientID field. 
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Goffin further teaches a ClientID field (Col 3: lines 49-61 , Col 4: 
lines 49-51 teaches transmission of video from a headend and a data 
router 202 that facilitates headend communications with the client device. 
Col 5: lines 34-44 and Col 6: lines 14-24 teaches that the data router 202, 
receives client ID from the client device). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include a Client ID field, as further taught by Goffin, for the advantage of 
allowing the server to easily and readily determine the source of the 
message. 

Consider claim 12, Solle, ISO/IEC 13818-6, and Goffin teach a 
confirmation message for confirming the session connection is transmitted 
from the digital broadcasting server to the client (Solle - Fig.1 , 1 2; Col 5: 
lines 26-32, 39-41 teaches that SIP systems can be either SIP clients or 
SIP servers, and direct session communications between SIP systems. 
Col 9: line 49 - Col 10: line 15 teaches establishing a session between 
SIP systems where an invite message {request from client} is sent and an 
Ok {confirmation} is received from the server; ISO/IEC 13818-6 - P.492- 
495 teaches a SDB-Server). 

ISO/IEC 13818-6 further teaches wherein a confirmation message 
for confirming the session connection is a SessionSetupConfirm message 
including: a DSM-CC (Digital Storage Media-Command and Control) 
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message header field, a Session ID (Identification) field, a response field, 
and a Server ID field (ISO/IEC 13818-6 - 4.2.4.2 on P 26-27, and Table 4- 
9). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include wherein a confirmation message for confirming the session 
connection is a SessionSetupConfirm message including: a DSM-CC 
(Digital Storage Media-Command and Control) message header field, a 
Session ID (Identification) field, a response field, and a Server ID field, as 
further taught by ISO/IEC 13818-6, for the advantage of for the advantage 
of allowing for a more flexible and versatile system, in order to be easily 
used in a digital broadcasting environment, allowing the client to easily 
process and start the correct session connection between the appropriate 
server. 

Consider claim 14, ISO/IEC 13818-6, and Goffin teach a client and 
a digital broadcasting server, directly requesting/receiving messages 
(Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492-495 teaches a 
SDB-Server), and wherein the confirmation message for confirming the 
status of the client is a ServerStatusConfirm message including: a DSM- 
CC (Digital Storage Media-Command and Control) message header field, 
a Response field, a statusType field, a resourceNumber field for showing 
a number of a resource whose status is wanted to be known, a 
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resourseStatus field (ISO/IEC 13818-6 - P.38-39 Section 4.2.9.4 
ClientStatusResponse {ServerStatusConfirm}; P. 60-61 teaches that 
resource descriptors may appear in a ClientStatusResponse 
{ServerStatusConfirm} message. P. 56-59 Section 4.7.1 teaches the 
various fields of a resource descriptor), but do not explicitly teach a 
ClientID field. 

Goffin further teaches a ClientID field (Col 3: lines 49-61 , Col 4: 
lines 49-51 teaches transmission of video from a headend and a data 
router 202 that facilitates headend communications with the client device. 
Col 5: lines 34-44 and Col 6: lines 14-24 teaches that the data router 202, 
receives client ID from the client device). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of ISO/IEC 13818-6, and Goffin to include a 
Client ID field, as further taught by Goffin, for the advantage of allowing 
the server to easily and readily determine the source of the message. 

Consider claim 16, ISO/IEC 13818-6, and Goffin teach a client and 
a digital broadcasting server, directly requesting/receiving messages 
(Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492-495 teaches a 
SDB-Server), and wherein the confirmation message for confirming a 
session termination is a ServerReleaseConfirm message including: a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field, a session ID field, a response field (ISO/IEC 13818-6 - P.29-30 
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Section 4.2.5.4 ClientSessionReleaseResponse {ServerReleaseConfirm}), 
but do not explicitly teach a ClientID field. 

Goffin further teaches a ClientID field (Col 3: lines 49-61 , Col 4: 
lines 49-51 teaches transmission of video from a headend and a data 
router 202 that facilitates headend communications with the client device. 
Col 5: lines 34-44 and Col 6: lines 14-24 teaches that the data router 202, 
receives client ID from the client device). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of ISO/IEC 13818-6, and Goffin to include a 
Client ID field, as further taught by Goffin, for the advantage of allowing 
the server to easily and readily determine the source of the message. 

Consider claim 19, Solle, ISO/IEC 13818-6, and Goffin teach a 
client and a digital broadcasting server, directly requesting/receiving 
messages (Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492- 
495 teaches a SDB-Server). 

ISO/IEC 13818-6 further teaches the client requesting for a session 
termination and terminating a session by receiving a confirmation 
message for the session termination (P. 81-82 teaches a client initiating a 
release request. Step 1 teaches the client directly sending a 
ClientSessionReleaseRequest message for releasing an existing session. 
Step 4-5 teaches receiving a ClientSessionReleaseConfirm message for 
terminating the session). 
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Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include the client requesting for a session termination and terminating a 
session by receiving a confirmation message for the session termination, 
as further taught by ISO/IEC 1 381 8-6, for the advantage of allowing the 
client to end connection with the server in a clean and efficient manner, 
allowing both parties to disconnect cleanly in a timely manner, allowing 
resources to be freed back into the network. 

Consider claim 20, Solle, ISO/IEC 13818-6, and Goffin teach a 
client and a digital broadcasting server, directly requesting/receiving 
messages (Solle - Fig.12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492- 
495 teaches a SDB-Server). 

ISO/IEC 1 381 8-6 further teaches requesting the client for a session 
termination and terminating a session by receiving a confirmation 
message for the session termination from the client (P. 87 - 88, step 2 
teaches sending a ClientSessionReleaselndication to the client for 
releasing an existing session. A ClientSessionReleaseResponse is 
received from the client and releases all the resources assigned to the 
session terminating the session for the client). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include requesting the client for a session termination and terminating a 
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session by receiving a confirmation message for the session termination 
from the client, as further taught by ISO/IEC 13818-6, for the advantage of 
for the advantage of allowing the server to end connection with the client 
in a clean and efficient manner, allowing both parties to disconnect cleanly 
in a timely manner, allowing resources to be freed back into the network. 

5. Claim 5 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Solle et al (US 6,757,732), in view of ISO/IEC 13818-6 (First edition 1998-09-01), 
in view of Goffin, II (US 6,918,135), and further in view of Chapman (US 
7,113,484). 

Consider claim 5, Solle, ISO/IEC 13818-6, and Goffin teach directly 
terminating a session between client and server (Solle - 624-Fig.12; Col 
10: lines 36-38), and a client and a digital broadcasting server, directly 
sending/receiving messages (Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 
13818-6 - P.492-495 teaches a SDB-Server). 

ISO/IEC 13818-6 further teaches, receiving at the client, a session 
termination request (P. 99 teaches receiving a 
ClientSessionReleaselndication for releasing session {session 
termination}). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include receiving at the client, a session termination request, as taught by 
ISO/IEC 13818-6, for the advantage of for the advantage of allowing the 
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server to end connection with the client in a clean and efficient manner, 
allowing both parties to disconnect cleanly in a timely manner, allowing 
resources to be freed back into the network. 

Solle, ISO/IEC 13818-6, and Goffin do not explicitly teach 
terminating a session if the client cannot transmit a response to the 
session termination request. 

In an analogous art Chapman teaches terminating a session if the 
client cannot transmit a response to the session termination request from 
the digital broadcasting server (Col 1 1 : lines 23-35 teach that if no 
response is received from the cable modem {client} the resources 
allocated to the session is de-allocated {terminated}). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include terminating a session {de-allocate resources} when no response is 
transmitted from the client, as taught in Chapman, for the advantage of 
freeing up resources for other clients. 

6. Claims 9, 11, and 15 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Solle et al (US 6,757,732), in view of ISO/IEC 1 381 8-6 (First 
edition 1 998-09-01 ), in view of Goffin, II (US 6,91 8,1 35), and further in view of 
Lalwaney et al. (US 6,289,377). 
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Consider claim 9, Solle, ISO/IEC 13818-6, and Goffin teach a client 
and a digital broadcasting server, directly sending/receiving messages 
(Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492-495 teaches a 
SDB-Server), and wherein the message for checking the status of the 
client is a ServerStatusRequest message including: a DSM-CC (Digital 
Storage Media-Command and Control) message header field, a Reason 
field, a statusType field, a resourceN umber field for showing a number of 
a resource whose status is wanted to be known, a Reserved field 
(ISO/IEC 13818-6 - P.38 Section 4.2.9.2; P. 60-61 teaches that resource 
descriptors may appear in a ClientStatuslndiction {ServerStatusRequest} 
message. P. 56-59 Section 4.7.1 teaches the various fields of a resource 
descriptor), but do not explicitly teach a ClientID field. 

In an analogous art Lalwaney teaches, a Client ID field (620 - Fig.6; 
Col 13: lines 16-32 and Col 6: lines 50-53 teaches a packet {message} 
that is transmitted from the cable operator network to the client). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include a Client ID field, as taught by Lalwaney, for the advantage of 
easily identifying the intended destination of the data, helping to ensure 
that the intended client will receive the data. 

Consider claim 11, Solle, ISO/IEC 13818-6, and Goffin teach a 
client and a digital broadcasting server, directly sending/receiving 
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messages (Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492- 
495 teaches a SDB-Server), and wherein a message for requesting a 
session termination is a ServerReleaseRequest message including: a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field, a session ID field, a Reason field (ISO/IEC 13818-6 - P.29 Section 
4.2.5.3 ClientSessionReleaselndication {ServerReleaseRequest}), but do 
not explicitly teach a ClientID field. 

In an analogous art Lalwaney teaches, a Client ID field (620 - Fig.6; 
Col 13: lines 16-32 and Col 6: lines 50-53 teaches a packet {message} 
that is transmitted from the cable operator network to the client). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include a Client ID field, as taught by Lalwaney, for the advantage of 
easily identifying the intended destination of the data, helping to ensure 
that the intended client will receive the data. 

Consider claim 15, Solle, ISO/IEC 13818-6, and Goffin teach a 
client and a digital broadcasting server, directly sending/receiving 
messages (Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492- 
495 teaches a SDB-Server), and wherein the confirmation message for 
confirming a session termination is a ClientReleaseConfirm message 
including: a DSM-CC (Digital Storage Media-Command and Control) 
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message header field, a session ID field, a response field (ISO/IEC 
13818-6 - P.29 Section 4.2.5.2), but do not explicitly teach a ClientID field. 

In an analogous art Lalwaney teaches, a Client ID field (620 - Fig.6; 
Col 13: lines 16-32 and Col 6: lines 50-53 teaches a packet {message} 
that is transmitted from the cable operator network to the client). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include a Client ID field, as taught by Lalwaney, for the advantage of 
easily identifying the intended destination of the data, helping to ensure 
that the intended client will receive the data. 

7. Claim 13 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Solle et al (US 6,757,732), in view of ISO/IEC 13818-6 (First edition 1998-09-01), 
in view of Lalwaney et al. (US 6,289,377). 

Consider claim 13, Solle teaches a method for controlling network 
digital service, comprising steps of: 

directly requesting, at a client, without passing through a network 
session resource manager, a digital server for a session connection, and 
establishing a session by receiving, without passing through said network 
session resource manager, a confirmation message for the session 
connection from the digital server (Fig.1, 12; Col 5: lines 26-32, 39-41 
teaches that SIP systems can be either SIP clients or SIP servers, and 
direct session communications between SIP systems. Col 9: line 49 - Col 
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10: line 15 teaches establishing a session between SIP systems where an 
invite message {request from client} is sent and an Ok {confirmation} is 
received from the server. These communications are direct from client to 
server as taught by Col 5: lines 39-41 and shown on Fig. 12, without 
passing a session resource manager); and 

Solle does not explicitly teach a digital broadcasting server and 
service; 

directly requesting at the client, without passing through the 
network session resource manager, the digital broadcasting server for a 
channel change, and changing a channel by receiving, without passing 
through the network session resource manager, a confirmation message 
for confirming the channel change from the digital broadcasting server, 

wherein a message for requesting the channel change and the 
confirmation message for confirming the channel change each include a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field, the confirmation message for confirming the channel change is a 
ProgramSelectConfirm message including: a DSM-CC (Digital Storage 
Media-Command and Control) message header field, a Session ID 
(Identification) field, a response field, a broadcast Programld field, and a 
Client ID field, and the ProgramSelectConfirm message is transmitted 
from the digital broadcasting server to the client. 

In an analogous art ISO/IEC 13818-6 teaches, a digital 
broadcasting server and service (P.492-495 teaches a SDB-Server); 
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directly requesting, at the client, without passing through the 
network session resource manager, the digital broadcasting server for a 
channel change, and changing a channel by receiving, without passing 
through the network session resource manager, a confirmation message 
for confirming the channel change from the digital broadcasting server (P. 
492-495 teaches a client directly requesting a broadcast program from the 
SDB Server. A SDBProgramSelectRequest is generated by the client and 
sent to the SDB Server for requesting a channel change. A 
SDBProgramSelectConfirm from the SDB Server is received by the client 
allowing the client to receive the requested Broadcast Program), 

wherein a message for requesting the channel change and the 
confirmation message for confirming the channel change each include a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field (P. 492-493; Fig. H-4. protocolDiscriminator, dsmccType, 
messageld, transcationld, reserved, adaptationLength, messageLength 
make up a DSM-CC message header field as taught in clause 2 on p. 7, 
which are all present in both messages for channel change and 
confirmation. P. 291 Sections 10.1.2-10.2), the confirmation message for 
confirming the channel change is a ProgramSelectConfirm message 
including: a DSM-CC (Digital Storage Media-Command and Control) 
message header field (P. 492-493; Fig. H-4. protocolDiscriminator, 
dsmccType, messageld, transcationld, reserved, adaptationLength, 
messageLength make up a DSM-CC message header field as taught in 
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clause 2 on p. 7, which are all present in both messages for channel 
change and confirmation. P.291 Sections 10.1.2-10.2), a Session ID 
(Identification) field, a response field, a broadcast Programld field, and the 
ProgramSelectConfirm message is transmitted from the digital 
broadcasting server to the client (Table 10-6, P.293 Section 10.2.3.2), 

privateData() field contains connection information necessary for 
the Client to receive the broadcast program (P.293 Section 10.2.3.2). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify Solle's system to include a digital broadcasting server 
and service; directly requesting at the client, without passing through the 
network session resource manager, the digital broadcasting server for a 
channel change, and changing a channel by receiving, without passing 
through the network session resource manager, a confirmation message 
for confirming the channel change from the digital broadcasting server, 
wherein a message for requesting the channel change and the 
confirmation message for confirming the channel change each include a 
DSM-CC (Digital Storage Media-Command and Control) message header 
field, the confirmation message for confirming the channel change is a 
ProgramSelectConfirm message including: a DSM-CC (Digital Storage 
Media-Command and Control) message header field, a Session ID 
(Identification) field, a response field, a broadcast Programld field, and the 
ProgramSelectConfirm message is transmitted from the digital 
broadcasting server to the client, as taught by ISO/IEC 13818-6, for the 
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advantage of allowing for a more flexible and versatile system, in order to 
be easily used in a digital broadcasting environment, allowing the client to 
switch channels with ease and control by authorizing the client to change 
channels, by providing all the necessary confirmation information allowing 
for a organized system. 

Solle and ISO/IEC 13818-6 teaches a ProgramSelectConfirm 
message (ISO/IEC 13818-6 - P.293 Section 10.2.3.2) that also contains a 
privateData field that contains connection information necessary for the 
Client to receive the broadcast program (ISO/IEC 13818-6 - P.293 
Section 10.2.3.2), but do not explicitly teach the message includes a Client 
ID field. 

In an analogous art Lalwaney teaches, a Client ID (620 - Fig. 6; Col 
13: lines 16-32 and Col 6: lines 50-53 teaches a packet {message} that is 
transmitted from the cable operator network to the client). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle and ISO/IEC 13818-6 to include a 
Client ID field, as taught by Lalwaney, for the advantage of easily 
identifying the intended destination of the data, helping to ensure that the 
intended client will receive the data. 

8. Claim 18 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Solle et al (US 6,757,732), in view of ISO/IEC 13818-6 (First edition 1998-09-01), 
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in view of Goffin, II (US 6,918,135), and further in view of Yun (US 
2007/0006254). 

Consider claim 18, Solle, ISO/IEC 13818-6, and Goffin teach a 
client and a digital broadcasting server, directly sending/receiving 
messages (Solle - Fig. 12; Col 5: lines 39-41; ISO/IEC 13818-6 - P.492- 
495 teaches a SDB-Server). 

ISO/IEC 13818-6 further teaches receiving at a client a message 
for checking a status of the client, and delivering a client status 
confirmation message indicative of the status of the client (P. 90-91 
teaches that the client can receive a ClientStatuslndication message 
which requests information. The client in turn sends back a 
ClientStatusResponse containing the information that was requested. 
Referring back to Table 4-16 on P.56, many different statusType fields can 
be used for specifying what type of status is requested including the status 
of the client). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
include receiving at a client a message for checking a status of the client, 
and delivering a client status confirmation message indicative of the status 
of the client, as further taught by ISO/IEC 13818-6, for the advantage of 
allowing the server to check on the state of the client in order to provision 
and utilize network resources more efficiently. 



Application/Control Number: 10/773,298 Page 
Art Unit: 2623 

Solle, ISO/IEC 13818-6, and Goffin do not explicitly teach the client 
periodically receiving a message from the digital broadcasting server for 
checking a status of the client. 

In an analogous art Yun also teaches the client periodically 
receiving a message from the digital broadcasting server for checking a 
status of the client (Paragraph 0090 teaches the cable head end 
transmitting the command {message} for periodically checking the 
operation state {status} of the set-top box {client}. The client {POD and 
set-top box} periodically receives these commands are sent periodically 
from the server to the client side). 

Therefore, it would have been obvious to a person of ordinary skill 
in the art to modify the system of Solle, ISO/IEC 13818-6, and Goffin to 
have the client periodically receive messages from the digital broadcasting 
server for checking a status of a client, as taught by Yun, for the 
advantage of providing the head end {digital broadcasting server} 
information regarding the set-top box in realtime (Yun - Paragraph 0073) 
and providing the head end with a more competitive edge (Yun - 
Paragraph 0035 - 0036). 



Conclusion 

9. Applicant's amendment necessitated the new ground(s) of rejection 
presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. 



Application/Control Number: 10/773,298 Page 
Art Unit: 2623 

See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as 
set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire 
THREE MONTHS from the mailing date of this action. In the event a first reply is 
filed within TWO MONTHS of the mailing date of this final action and the advisory 
action is not mailed until after the end of the THREE-MONTH shortened statutory 
period, then the shortened statutory period will expire on the date the advisory 
action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be 
calculated from the mailing date of the advisory action. In no event, however, will 
the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to JASON K. LIN whose telephone number is 
(571 )270-1446. The examiner can normally be reached on Mon-Fri, 9:00AM- 
6:00PM, EST. 

If attempts to reach the examiner by telephone are unsuccessful, the 
examiner's supervisor, Brian T. Pendleton can be reached on (571)272-7527. 
The fax phone number for the organization where this application or proceeding 
is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from 
the Patent Application Information Retrieval (PAIR) system. Status information 
for published applications may be obtained from either Private PAIR or Public 
PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll- 
free). If you would like assistance from a USPTO Customer Service 
Representative or access to the automated information system, call 800-786- 
9199 (IN USA OR CANADA) or 571-272-1000. 

Jason Lin 
07/05/2008 



/Brian T. Pendleton/ 

Supervisory Patent Examiner, Art Unit 2623 



